2023年随手记第三十七篇，继续总结R17中UE省电节能的另一个重要功能--PEI。R17中引入了两类多个UE power saving功能：Idle/Inactive态与连接态。每类中又包含了若干小类。本文所要重点总结的PEI属于Idle/Inactive态中的一类重要功能。

由于传统的paging通常是通过TA List来确定paging范围的。在早期的R15中，false paging是经常发生的，而且不经常被paging的UE却总是会被动地接收paging消息从而消耗大量的电能。

为了减少由于错误寻呼引起的UE功耗，监视同一PO的UE组可以进一步划分为多个子组。对于子组，如果UE所属的子组通过相关联的寻呼早期指示（PEI）所指示的那样被寻呼，则UE应当监视其PO中的PDCCH以进行接收寻呼调度。由于子分组降低了误寻呼概率，因此可以相应地降低空闲/非活动模式下的UE接收功耗。如果UE不能监视与其PO相对应的相关联的PEI时机，则它应当监视其PO中的寻呼。更通俗的白话说PEI的概念原理：

UE在其寻呼时机（PO）之前被通知，这样UE就可知道是否必须监听。因此，如果UE不需要监听PO，则UE可以跳过PO之前的时间-频率同步。

PEI的另一个重要之处在于，它可以携带子分组信息，以将共享相同寻呼时机PO的UE划分为子组。这导致较低的组寻呼速率和较少的错误寻呼。这些子组可分为两类：一类是CN controlled，另一类是UE ID based：

每个cell中最多使用8个subgroup，包括由网络配置的CN控制的子分组和基于UE ID的子分组的总和。如果在PEI中为CN控制的子组分配了相应的指示，则具有CN控制的 subgroup ID的UE应当应用CN控制的subgroup ID；否则，如果小区仅支持基于UE ID的子组，则其使用基于UE ID的subgroup ID。在规范文本中的几个约定：第一，如果UE支持PEI功能，则其至少支持UE ID based subgrouping方式。

第二，PEI监测可以选择性地通过系统消息限制到最后使用的小区；

第三，PEI监听基于为DCI格式2_7设置的Type2A PDCCH公共搜索空间（CSS），其中CRC由MCG的主小区上的PEI-RNTI加扰。DCI格式2_7的寻呼指示字段的每个比特指示寻呼时机的一个UE子组；

第四，PEI时机（PEI-O）是一组PDCCH监视时机（MO），并且可以由多个时隙（例如，子帧或OFDM符号）组成，其中可以发送PEI。与一个PEI-O相关联的PO数量是与最多两个寻呼帧（PF）相关联的总PO数量的一个因子。

第五，UE的PO的PEI-O的时间位置由参考点和从参考点到该PEI-O第一PDCCH监视时机的开始的符号级偏移来确定。参考点是参考帧的开始，该参考帧由从与PEI-O相关联的PF中的第一个PF的开始的帧偏移确定。可以配置PEI-O的时间位置，使得可以最小化空闲/非活动模式下的总UE接收功率消耗，包括同步和RRM测量。

如上，DCI2-7可以灵活地包含subgroup指示，处于IDLE/Inactive UE监听PEI的搜索空间，并且在检测到当前PEI指示时，UE监视下一个PO。否则，UE/深度休眠并跳过对PO的检测。与实际的寻呼PDCCH相比，可实现的功率节省增益是由于更有限的PEI搜索空间。因此，对于未被寻呼的UE，PEI减少了不需要的寻呼时机解码的数量，即减少了false paging。这个机制可展示如下：

此外，如前面所述的，DCI2-7可以被定义用于某一组IDLE/Inactive UE。特别地，IDLE/Inactive UE通过几个引入的分组被分组在几个寻呼组中，并且PEI DCI以特定组的方式被加扰。因此，当IDLE/Inactive模式UE在用其自己的寻呼组扰码解码PEI DCI之后计算循环冗余校验（CRC）时，它假设所发送的PEI是针对一个或多个其它寻呼组的，并且相应地跳过PO，导致false paging的进一步减少。更为通俗的说PEI，其主要通知UE是否接收下一个PO（在接收PO之前通知UE）。因此，UE可以通过监测所需的SSB来确定是否准备PO接收，如上图所示。否则，UE可能会休眠。PEI的节能潜力在于减少了SSB监测和PDCCH+PDSCH接收，并因此增加了睡眠时间来节能。而对于引入subgroup的好处在于，传统的paging是多个UE共享PO，这有可能导致较多的false paging，而subgroup机制能将一个PO的UE分成若干个子组来降低false paging。如果UE所属的子组经由相关联的PEI所指示的那样被寻呼，则UE将监视其PO中的PDCCH以进行寻呼过程。而如果UE在小区中找不到其具有PEI配置的子组ID，或者如果UE不能监听到与其PO相对应的相关联的PEI时机，则其应当监视其PO中的寻呼。

CN Controlled subgrouping流程如下：

Step1：UE通过NAS信令消息指示网络其支持CN Controlled subgrouping。

Step2：如果UE支持CN Controlled subgrouping，AMF确定分配给UE的subgroup ID。

Step3：AMF将subgroup ID通过NAS消息发送给UE。

Step4：AMF将分配的同于paging UE（Idle/Inactive态）的subgroup ID通知gNB 。

Step5：通过step3和step4，UE和gNB均获取了相应的subgroup ID。那么当paging消息（来自CN或者gNB产生），gNB将确定与UE关联的相应的PO和PEI-O。

Step6：在paging该UE之前，gNB发送所关联的PEI，并指示要在PEI中寻呼的UE的对应CN控制的subgroup。

重申下，在UE ID based subgrouping中，gNB和UE可以基于UE ID和小区中用于基于UE ID的子组的子组总数来确定子组ID。基于UE ID的子组的子组总数由每个小区的gNB决定，并且在不同的小区中可以是不同的。下图描述了基于UE ID的子分组的过程：

Step1：gNB确定小区中UE ID based subgrouping的subgroups总数。

Step2：gNB在小区中广播UE ID based subgrouping的subgroups总数。

Step3：UE确定其在小区中的subgroup。

Step4：当gNB从CN接收到或由gNB生成用于具有PEI能力的UE的寻呼消息时，gNB确定UE的PO和相关联的PEI时机。

Step5：在PO中寻呼UE之前，gNB发送相关联的PEI，并指示基于在PEI中寻呼的UE的UE ID导出的对应子组。

PEI的系统处理流程细化：

如前面所述，在SIB1中的PEI-Config IE包含了PEI相关的众多信息：

在NG接口上的消息包括（详细查38.413 R17版本）：

InitialContextSetupRequest

PathSwitchRequest

Paging messages

相关F1AP的消息如下（参考38.473 R17）：

相关的NAS消息如下（参考24.501 R17）：

38.213中定义了PEI的处理逻辑，基本是基于本文以上的信息：